Summary

Five GitHub-touching MCP servers (comment, inline-comment, github-state, resolve-review-thread, merge-readiness) and the shared state-fetchers.ts fetcher returned raw Octokit error messages directly to the agent's tool-result channel. Those messages echo the full credential URL (https://x-access-token:<ghs_token>@api.github.com/...) and Authorization: Bearer <token> headers with no redaction — OWASP MCP01 tool-result token leakage. merge-readiness had a hand-rolled inline regex that had already drifted from the canonical redactor; the other four did nothing.

A second, live gap was closed during review: the canonical redactGitHubTokens / redactSecrets regexes in src/utils/sanitize.ts only matched the legacy 36-char ghs_ body. GitHub's 2026-04-24 changelog announces a new ~520-char stateless ghs_APPID_JWT installation-token format, rolling out to all App installation tokens mid-May–late-June 2026, and explicitly names ghs_[A-Za-z0-9]{36} as a regex that will break. This app mints installation tokens itself, so its own live token was about to become unredactable. The ghp_/gho_/ghs_/ghr_ patterns are widened to GitHub's recommended open-ended [A-Za-z0-9._-]{36,} shape so both the legacy and new-format tokens are scrubbed.

Flow

flowchart TD
    OctErr["Octokit error<br/>echoes credential URL and Bearer header"]:::new --> Redact["redactErrorMessage<br/>redactCredentialUrls then redactSecrets<br/>byte-deletion only, no marker"]:::new
    Redact --> AgentResult["agent tool-result<br/>credential-free"]:::keep
    TokenRegex["GitHub token patterns widened<br/>open-ended body, 36 or more chars<br/>covers legacy and new stateless token"]:::new --> SanitizePipe["redactSecrets pipeline"]:::keep
classDef new fill:#1a5276,color:#ffffff
classDef keep fill:#ecf0f1,color:#2c3e50

Before: Octokit error → raw string (credential URL / Bearer header) → agent tool-result. redactGitHubTokens matched only exactly-36-char ghs_ tokens; new ~520-char installation tokens passed through unredacted.

Changes

• src/utils/log-redaction.ts — new config-free helper redactErrorMessage(err): extracts the message string, runs redactCredentialUrls then redactSecrets, returns the cleaned body. Byte-deletion only, no [REDACTED_X] marker (CLAUDE.md security invariant 2 — markers leak probing signal on output paths).
• src/mcp/servers/{comment,inline-comment,github-state,resolve-review-thread,merge-readiness}.ts — every catch now routes through redactErrorMessage instead of raw err.message. merge-readiness's divergent inline regex is deleted.
• src/github/state-fetchers.ts — sixth catch site (dispatchGithubStateTool) wired to redactErrorMessage. Stays config-free (log-redaction imports only pino + sanitize).
• src/utils/sanitize.ts — ghp_/gho_/ghs_/ghr_ token regexes widened from {36} to open-ended [A-Za-z0-9._-]{36,} (input-side redactGitHubTokens and output-side redactSecrets in parity) so the new ~520-char ghs_APPID_JWT format is scrubbed. Ordering invariant documented: the GitHub-token patterns must stay above the JWT pattern, since a stateless token embeds a JWT.
• test/utils/log-redaction.test.ts — unit tests for redactErrorMessage: bare token, Bearer header, credential URL, the new ~520-char format, and benign passthrough (Error + non-Error).
• test/mcp/error-redaction-wiring.test.ts — source-assertion guard binding each of the 6 catch sites to = redactErrorMessage(, so the wiring cannot silently regress without a heavyweight MCP subprocess harness.
• test/utils/sanitize.test.ts — new-format (~520-char) ghs_ case added to the canonical token-redaction suite.

Related issues

Closes #224

Test plan

• redactErrorMessage unit tests incl. the new ~520-char ghs_APPID_JWT shape (bare / Bearer / credential URL)
• Source-assertion wiring guard for all 6 catch sites
• New-format token case in the canonical sanitize suite
• typecheck / lint / format clean
• The local full bun test shows pre-existing DB-skip noise only; the isolated CI runner (scripts/test-isolated.sh) reports 0 genuine assertion failures and all target test files pass